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TRANSACTIONAL COMPUTER SYSTEM 

BACKGROUND OF THE INVENTION 

This invention relates to a transactional computer system, 
namely a computer system adapted to perform negotiation and decision 
making functions related to a transaction. 

Transactional computer systems are known for use in the 
financial and business world for conducting transactions such as, 
for example, ordering product, currency exchange, or the sale and 
purchase of stock, shares and bonds. Such systems are designed 
specifically for the particular function or functions which they are 
to perform. 

Rule-based systems using what is generally known as artificial 
intelligence are also known. These are based on a large number of 
rules which are specific to the particular environment in which they 
are to be used. A given system is designed for a particular type of 
transaction, and if a new type of transaction is envisaged a new 
system will have to be designed specifically for that purpose. 

I have appreciated that it would be highly desirable to 
provide a generalised transactional system which can be adapted to 
many specific types of transaction, and furthermore I have 
appreciated that such a generalised transactional computer system 
can be made by using the ideas and features described in the 
following and claimed in the claims appended to thi5fes**description . 

SUMMARY OF THE INVENTION 

The invention is defined in the independent claims below to 
which reference should now be made. Advantageous features are set 
forth in the appendant claims. 

According to the present invention there is provided a 
transactional computer system comprising a plurality of entities 
including at least one entity of each of the following forms, a 
first entity (Thing entity) having the properties of identifying a 
client system and uniquely identifying an object in that client 



system, a second entity (Proposal entity) for defining a 
transaction, the second entity being subordinate directly or 
indirectly to a first entity and having the properties of modelling 
at least one external agent to carry out a transformation in 
5 relation to the first entity, and a third entity (Decision entity) 
capable of communicating with a second entity and having the 
properties of defining the types of decision that may be made, and 
determining the responses in relation to those decisions. 

Preferably the computer system further comprises at least one 

10 fourth entity (Assignment entity) subordinate to an associated first 
entity, the fourth entity having the properties of uniquely 
identifying the associated first entity, and identifying a 
particular type of assignment or transformation to be applied to the 
first entity. This entity may be combined with the second entity. 

15 Additionally the computer system preferably further comprises 

at least one further entity (Tender entity) associated with a 
plurality of second entities and a single first entity, and 
identifying at least a quantity. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will now be described in more detail by way of 
example, with reference to the drawings, in which: 

Figure 1 illustrates the hierarchical structure of the 
5 entities in a preferred computer system embodying the invention; 

Figure 2 is a flow chart illustrating the NewEntity procedure 
in the preferred embodiment of the invention; 

Figure 3 is a flow chart illustrating the RegisterEntity 
procedure in the preferred embodiment of the invention; 
10 Figure 4 is a flow chart illustrating the LoadHierarchy 

procedure in the preferred embodiment of the invention; 

Figure 5 is .a flow chart illustrating the Math: AddDecision 
procedure in the preferred embodiment of the invention; 

Figure 6 is a flow chart illustrating the Cube: Apply Decision 
15 procedure in the preferred embodiment of the invention; 

Figure 7 is a flow chart illustrating the Item (EntityKey ) 
procedure in the preferred embodiment of the invention; 

Figure 8 is a flow chart illustrating the Math: GetMathValue 
procedure in the preferred embodiment of the invention; and 
20 Figure 9 is a flow chart illustrating the Cube: GetValue 

procedure in the preferred embodiment of the invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

GENERAL DESCRIPTION 
This system is embodied in a computer software module which, 
5 when included in a client system, will capture the complexity of its 
negotiations, but leave the description of those transactions to the 
client system. The system makes possible the management of the 
transaction space in a straightforward and effective manner. It 
does not, however, manage the transaction space directly. Rather, 

10 it supports the modelling of the transaction space in a convenient 
and effective manner, and then, once modelled, it is for the client 
system to respond to the situations discerned and captured in the 
model. The power of the system is in its flexibility for modelling 
and managing the client system's complex transaction space. 

15 The system will only capture and supply information without 

using it for its own internal manipulation. It is better to record 
what people claim, and then leave the external clients/parties to 
resolve their claims, than it is to try to decide the truth of a 
matter. Consequently, the validity or otherwise of the supplied 

20 information has no bearing on the system. However, it may have a 

significant bearing on the satisfactory use of the system; therefore 
the client system should validate the information supplied and act 
accordingly . 

The system comprises a hierarchy of entities: a Thing, a 
25 Proposal and a Decision, and optionally an Assignment and/or a 

Tender. Each entity type has a set of properties appropriate to its 
role. These are described in more detail below as part of the 
preferred embodiment. It is a feature of the system that an 
extension of the modelling environment can be achieved by the 
30 provision of additional properties per entity. 
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THE THING ENTITY 
The system supports the modelling of the existence of external 
objects by provision of a 'Thing' entity. In the preferred 
embodiment, the Thing entity has fields ClientSystem, and 
5 ClientSystemRef erence . The ClientSystem field is an identifier of 
the client system itself, and the ClientSystemRef erence field is an 
identifier by which the implicit existence of an object identified 
by that Reference is posited. 

No validation as to the nature of that implicit object is 
10 either attempted or warranted, nor of any other information 
pertaining to the world outside the system. 

A ClientSystemRef erence to a Thing must be unique, so that all 
behaviours and data to a common external thing will be mapped and 
managed by a common internal Thing. Client applications must ensure 
15 that they have implemented an appropriate nomenclature to ensure 
unique references per client system. 

THE ASSIGNMENT ENTITY 
The system supports the modelling of assignments or 

20 transformations applied to external objects. It does so by 
provision of an 'Assignment* entity. An Assignment, for the 
purposes of the system, is regarded as a transformation that may be 
applied to a Thing, for example an operation which can be conducted 
in relation to an object. Thus, in the system's entity hierarchy, 

25 an Assignment is subordinate to and applies to a Thing. 

An Assignment will comprise in particular an identifier for 
the particular type of assignment or transformation to be applied. 
This key information is supplied by the external client system in 
the Assignment's 'Redirection' field, see below. 

30 Timing of an assignment will often be significant to the 

external client. A facility to recognise timing may, if desired, be 
provided by the inclusion of fields appropriate to each of the 
distinct entity types. In particular, fields relating to overall 
deadlines for Assignments may be included in that entity. 
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LINKING ASSIGNMENTS 
The system supports sequential modelling of assignments. As 
an example: with a Thing (CAR), Assignment (WASH) might be followed by 
Assignment (DRY) . The assignment sequence is maintained by referring 
5 to WASH as the predecessor to DRY. 

THE TENDER ENTITY 
The client system is allowed to group together a set of 
proposals, thus allowing more complex negotiation behaviours to be 
10 modelled. For example, as its name implies, Tenders and auctions 
may be modelled. The system allows the creation of the Tender 
entity and notes its corresponding external reference. 



THE PROPOSAL ENTITY 

15 The system includes an important facility to model the 

existence of agents to carry out the transformations. As an example 
this might be a cleaning machine which is required to wash a car. 
This is supplied by a 'Proposal 1 entity. 

A client system wishing to identify the potential for an agent 

20 to impact an assignment's fulfilment will create a Proposal. Since 

in the preferred embodiment the Proposal has a bearing on a 
particular Assignment, it is subordinate to an Assignment in the 
hierarchy and in the preferred embodiment applies to a single 
Assignment only. Where there is no Assignment entity, a Proposal 

25 may be subordinate to a Thing; either way it is seen that a Proposal 
is subordinate directly or indirectly to a Thing. 

The identification of an agent by a client system is at no 
time validated by the system, but is deemed to be supplied by the 
client system as a rational and satisfactory identity. 

30 The system provides for modelling situations where the 

potential action of the agent may often have arisen as a matter of 
negotiation. The counter-party to the agent in this negotiation is 
also identifiable by the client system. 

The system includes a facility to distinguish the current 

35 direction of the negotiation. 

The Proposal itself carries a rich set of features, sufficient 
and appropriate to the complexity of the environments it is intended 
to be capable of modelling. 
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The preferred embodiment supports the following features 
within a Proposal, each being a field supporting input by the client 
system. The identity of the agent capable of impacting the 
Assignment is held in the field 'Downline'. The counterparty to the 
5 agent in this negotiation is held in the field 'Upline'. In regard 
to a specific proposal, the Upline will have no direct impact upon 
the Assignment. The direction of the negotiation is implemented as 
a boolean flag ' DirectionGoingUp ' , which may be either true or 
false . 

10 For example, a proposal going DOWN, whereby the party making 

the proposal is the Upline and expects a reply from the Downline, 
models a request or command. Conversely, a proposal going UP, 
whereby the party making the proposal is the Downline and expects a 
reply from the Upline, models the function of volunteering. 

15 A proposal is something to be considered and a decision made 

on it. A proposal is therefore conveniently recorded using the 
expression Consider. Do, as will be seen below. 

As indicated above, a facility to recognise timing may be 
provided by the provision of fields to reflect the same. Deadlines 

20 for making a decision, and for complying (completing an assignment) 

may be included in the Proposal Entity. 
GROUPING PROPOSALS 
By grouping proposals it is possible to extend the flexibility 
of the modelling environment to support the tracking of complex 

25 interactions. For example, cause and effect, flow modelling, 

command and control and the like, can be grouped. This grouping is 
accomplished by using Subordinate Proposals and Sibling Proposals. 

SUBORDINATE PROPOSALS 

30 A further feature of the preferred system is the modelling of 

subordinate proposals. For example, in a factory, a 
Thing (CLIENTORDER) with an Assignment ( FILL ) may require a sequence 
of proposals before it can be fulfilled. This may include the 
interaction of several people. These proposals should be grouped 

35 together. To achieve this the ProposallD of the Superior proposal 

is recorded in all subordinate proposals using the field 
Super iorProposalRef ID . 
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SIBLING PROPOSALS 
A further feature of the system is the grouping together of 
proposals regarding the same matter. For example, if in a warehouse 
a customer wants 1000 ball bearings, but there is only 800 on the 
5 shelf, then 200 will have to be refused. All of this information 

will be stored in many proposals, but all regarding the same matter 
(i.e. the order for 1000 ball bearings). To achieve this grouping 
all sibling proposal entities store the original ProposallD in the 
field SiblingProposalRef ID. 



COMBINED PROPOSAL/ASSIGNMENT ENTITY 
As described above, the assignment entity is optional. The 
features of the assignment entity, if included, may be combined with 
15 a proposal entity to provide a combined proposal/assignment entity 

which has the properties of both a proposal entity and an assignment 
entity . 

THE DECISION ENTITY 

20 The system records the response from the counter-party in 

regard to a corresponding proposal. This is the role of the 
Decision Entity which is subordinate to and can communicate with a 
single one of the Proposals. Delegated proposals are tracked by 
passing the Decision for a Subordinate Proposal to the Superior 

25 Proposal. An individual position in a negotiation is tracked by 

passing a Decision for a Sibling Proposal to all the other Sibling 
Proposals with the same SiblingProposalRef ID field. 

The response recorded by the decision entity can be: decline, 
accept, partially accept, or forward. Forwarding involves accepting 

30 the proposal but finding another agent actually to undertake it. 

The responses are recorded in the form Decline. Do, or Accept. Do, and 
so on, as appropriate. 
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THE DECISION SCHEMA 
In order to derive effective meaning from the system, external 
decisions need to be recorded in a consistent, effective and 
intuitive manner. The protocol for so doing is implicitly provided 
5 by the creation of a logical structure, termed the decision schema. 
The decision schema comprises multiple dimensions and defines what 
types of decision may be stored. Each dimension comprises a set of 
direct fields and a set of derived fields: 

Direct f ields , define the types of decision that may be 
10 stored. 

Derived fields summarise the consequences or impact of 
the decision. 

It is desirable that the direct fields represent a set of 
mutually exclusive states, whereas the derived fields need not be 

15 mutually exclusive. Each field is assigned an index into the 
dimension. A decision type node is then defined as a vector, 
comprising one index from each dimension. Decisions of that type 
have their quantities applied to that node, so that each node 
accumulates a summary of like decisions. 

20 The Decision Schema is a facility which client applications 

may use to model complex negotiations in a manageable and effective 
manner. A client application must, however, be clear as to its 
decision semantics, in order to make use this feature. An example 
of a Decision Schema is given below in the more detailed description 

25 of the preferred embodiment. 



THE DECISION CUBE 
A decision cube is built in the code in the form of a 
multidimensional array. It is used to store the quantities 
30 associated with each decision. Each element of the array should be 
initialised to zero. 



DESIGN PRINCIPLES FOR DECISION SCHEMAS 
Decision states (within a dimension) are exclusive. It is 
35 meaningless to record both an agreement to NotDo something, and yet 
that it is Done. If an agent agrees to NotDo something, and yet 
declares it Done, then it is regarded in the context of the system 
as a rogue agent . 
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The decision cube does not preclude recording inappropriate or 
meaningless information. As noted above, it is a fundamental design 
principle that it is better to record what people claim, and then 
leave the external clients (or parties) to resolve their claims, 
5 than it is to try to decide the truth of a matter. Thus the system 
can record both a NotDo and a Done, and let the client system scan 
for such occurrences, and then implement whatever procedures 
necessary at that point. 

Decision states may be partial. This requires the proposal to 

10 have a Quantity. For example: a proposal to ship 12 crates of water 
(Consider. Do . 12 ) may have the response: Accept. Do. 6, Decline . Do . 4 ; 
leaving 2 undecided (Pending) . 

This also leads to a further observation: that a proposal 
using a Quantity is deemed to refer to a homogeneous assignment. 

15 Thus, with shipping bottles of water, it is assumed that the parties 
to the proposal are indifferent between two bottles of water from 
the same assignment. If partial quantities need to be 
differentiated, then they should be differentiated as different 
Things, and then renegotiated accordingly. Thus a crate of 20 

20 pieces of fruit (12 Apples and 8 Oranges) is perfectly acceptable as 
a Thing, provided the system is not expected to discriminate between 
Apples and Oranges. If it is, then it should be registered as 2 
shipments: one of Apples [Quantity 12], and the second as Oranges 
[Quantity: 8] 

25 

OPTIONAL ENTITIES 
The entities Assignment and Tender are optional members of the 
hierarchy. Specifically a Proposal may be created for a Thing 
without requiring an Assignment or Tender. This facility is 
30 provided to support very simple scenarios, without the overhead of 
the unnecessary creation of Assignment and Tender entities. The 
hierarchy will always include Thing, Proposal and Decision entities. 
This hierarchical structure is illustrated in Figure 1. 
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REQUIREMENTS 

The basic requirements needed to support a physical 
implementation of the system are: 

A facility to define the distinct Entities, their 
5 Properties, and the Values associated with these 

Properties . 
A facility to create the Entities 
A facility to have such Entities persist. 

A facility to identify particular instances of Entities. 
10 A facility to set, edit and retrieve the Property Values 

of such Entities. 
A facility to manipulate Entities in a Hierarchy. 

THE PREFERRED EMBODIMENT 
15 The processes required to implement the system will now be 

described in more detail, including in particular the construction 
of the Entity hierarchy, and adding decisions to the hierarchy. 

The specific functions (processes) described in more detail 
below are : 

20 

NewEntityO The facility to create a new member entity of 

the hierarchy 

RegisterEntity ( ) The facility to load an entity (into memory) 
LoadHierarchy ( ) The facility to load directly a full 

25 subordinate tree 

ApplyDecision ( ) The facility to increment the multidimensional 

data array, or cube 
Item() The facility to retrieve a pointer to a member 

entity 

30 Cube: GetValue ( ) The facility to retrieve a cube's value at a 

particular node 
Notif yEvent ( ) Advising Client System of an event 

Of these functions, only two are intended to be accessible to 
35 clients/parties external to the system, namely NewEntityO and 

Item(). The function LoadHierarchy ( ) could be achieved by multiple 
applications of RegisterEntity ( ) but it is convenient to have it 
available as a separate function in its own right. 
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The only further facility required to provide an effective 
minimal embodiment of the system is then: 

EntityPropertyValue ( ) : Retrieve the Value of a Property of an 

Entity . 

5 This is a trivial process and need not be further discussed. 

The utility of the system will often require a client 
application to be able to determine the state of a particular 
entity, by examining its properties. This function provides that 
facility. 

10 The following describes the sequencing and sub-processes 

necessary to support each of the key function processes highlighted 
above. The descriptions, should be read in conjunction with the 
flowcharts in Figures 2 to 9 with the same title. Numeric 
references refer to these flow-charts individually. 

15 In the preferred embodiment of the system, the hierarchy 

consists of Things, Assignments, Tenders, Proposals and Decisions. 
Since their processing internal to the system is largely similar, it 
is more convenient to regard them all as instances of a generalised 
Entity. An implementation of NewEntityO therefore may be read as 

20 "Construct a facility, of the type: NewEntity (EntityTypeName) 

where EntityTypeName is one of: Thing, Assignment, Tender, 
Proposal, Decision. 11 
This allows further hierarchies to be readily developed, but at the 
cost of more sophisticated code to handle the distinct types. 

25 

Notation: 

Numbers: 1. Numbered boxes in the accompanying 

flow-charts . 

Restrictions: [Thing only] Entities only of [this] type 

30 Exclusions: [Not Thing] Entities not of [this] type 

Universal: [All] Entities of all Types. 

NewEntity () 

This is the facility to create a new member entity of the 
hierarchy and is illustrated in Figure 2 of the drawings. The 
35 procedure applies to all the entities Thing, Assignment, Tender, 

Proposal, and Decision. Note however that Step 1 applies only to a 
Thing, Step 4 does not apply to Decision, and Step 5 applies only to 
Decision. 
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Arguments: The properties of that Entity. See Entity Properties, 

below . 

1. [Thing only] A Client Reference to a Thing should be unique. 
A check is made to see if such a Client Reference already 

5 exists. 

la. If it does, the process is deemed to have failed. 

2. [All] Add a new record to the appropriate EntityType database 
table. Include the data from the arguments to the NewEntityO 
call . 

10 3. Retrieve a unique ID (within that EntityType) for the new 
entity . 

4. Register () the new entity in memory, see below and Figure 3. 
(Create a new object in memory, of that type, with the 
appropriate data as supplied by the arguments in the call to 

15 the function.) 

5. Proposal: Math: AddDecision ( ) , see below and Figure 5. Since 
something has happened which could have a bearing on the 
client systems behaviour (e.g. a new Thing to be considered, 
new Assignment to be processed, new Tender to be negotiated, 

20 Proposal to be considered, or Decision to be evaluated) , an 

EventNotif ication is sent out to the client system to make it 
aware of the event, in particular its type, and its ID. See 
Notif yEvent ( ) 

6. Notif yEvent () . Finally, an ID is returned (non-zero, in this 
25 embodiment) , unique within the EntityType, so that the caller 

of the process may subsequently refer to this particular new 
entity, in calls to Item(), by its new EntityName. 
Regis terEntity ( ) 

This is the facility to load an entity (into memory) , and is 
30 illustrated in Figure 3 of the drawings. The procedure also applies 
to all the entities Thing, Assignment, Tender, Proposal, and 
Decision. Note however that Steps 2, 3, 4 and 6 do not apply to a 
Thing, Step 3 does not apply to Assignment, Step 7 does not apply to 
Decision, and Step 9 applies only to Thing. 
35 Arguments: The properties of that Entity. See Entity Properties. 

Arguments: In addition, the ID f s of the Entity's superiors in the 

Hierarchy . 
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A check is made, to discover whether this particular entity 
has already been loaded. If so, there is no need to load it 
again. Processing proceeds to Step 11, where a Pointer to the 
Entity is returned, so that the calling function may directly 
reference its properties. 

[Not Thing] Item(): Get pointer to superior thing, see below 
and Figure 7. As the EntityType 'Thing 1 , is the root of the 
Hierarchy structure, all instances of subordinate EntityTypes 
(but not a Thing itself, hence the exclusion) will have a 
superior Thing. This step proceeds to get a reference to the 
entity's superior Thing, by a call to Item (ThingID) . The 
ThingID is passed, along with the ID's of any other superior 
entities, in the call to the function. As a further 
consequence of the call, since Item() will load the Thing if 
not already loaded, it will load the full hierarchy particular 
to this Thing, including the entity which is being attempted 
to be registered. Hence this call is recursive if the Thing 
was not already loaded. Thereafter, the Thing being loaded, 
there is no further call to load the hierarchy, and hence to 
register the entity which originated the call to Thing. In 
the recursive case, this process again checks to see whether 
or not the subject of the original call has now in the interim 
been loaded. 

[Not Thing, Not Assignment] This step calls, Item () as required 
to get pointers to further superior entities. A Thing has 
none, and as Assignment has only a superior Thing, so both are 
excluded from this step. These pointers will be used in Step 
6, to allow an entity to directly reference its superiors. 
This step also provides an opportunity to ensure that the 
superiors specified in the call to this function are all 
available, and appropriate to the entity being registered. 
[Not Thing] See Step 2. Due to the recursive nature of the 
call to Item (ThingID) , this step checks to see whether the 
originally requested entity has now in the interim been loaded 
in memory. 

[All] In this step, a blank (uninitialised, data unspecified) 
instance of this class of entity is created in memory. 



6. [Not Thing] All objects other than a Thing will have 
superiors. In this step, the pointers gathered in Steps 2 and 
3 are now assigned to appropriate properties in the new memory 
instance. In this particular embodiment, only the immediate 
superior in the hierarchy is assigned to the new memory 
entity. Higher superiors may then be accessed by chaining 
entity properties, e.g.: 

(Visual Basic) Proposal . Tender .Assignment 

(C++) Proposal ( ) ->Tender ( ) ->Assignment ( ) . 

7. [Not Decision] Create and link a Math Crystal. This step 
assigns the property values, passed as function arguments, to 
the appropriate Obj ect . Properties . Hereafter, a client system 
or internal routine will be able to directly determine the 
state of the object, by accessing these Property Values. 

8. Assign the Entity's data. 

9. [Proposal Only] A Proposal has a Property Quantity or more 
exactly Consider Quantity. This is the amount that is being 
offered for consideration. Where the field is not used or 
required, it may be deemed to have a value 1. It is therefore 
meaningless to consider the impact of decisions (how much has 
been agreed, etc.) if the original target is not known. This 
step therefore adds a Decision as a "Consider", with Decision 
parameters Action and BidWanted derived from the proposal 
properties . 

10. [Thing Only] LoadHierarchy ( ) , see below and Figure 3. As 
described earlier and elsewhere, loading a Thing also loads 
the entire hierarchy subordinate to a Thing. It is achieved 
by a call to the LoadHierarchy ( ) function. 

11. [All] Processing complete, the process will return a Pointer 
to the newly created memory object. 

LoadHierarchy ( ) 

This is the facility to load directly a full subordinate tree, 
and is illustrated in Figure 4. Note that Section I comprising 
Steps 1 to 5 processes the intermediate entity types Assignment, 
Tender and Proposal. Section II comprising Steps 6 to 9 processes 
the entity type Decision. 



Arguments: The ID (ThingID) of the Thing whose hierarchy is to be 

loaded. 

The process needs to load all the Assignments , Tenders and Proposals 
associated with a Thing. It does this by Registering the Entities. 
5 The procedure is described therefore as follows. 
Section I . 

1. [Not Thing, Not Decision] The process initiates a sub-process 
for each intermediate EntityType in turn. The hierarchy 
subordinate to a Thing is being loaded, so Thing is redundant 

10 and excluded. Decisions are treated differently, later, and 

so here excluded. 

2. Each EntityType 1 s stored data (database table, in this 
embodiment) is searched for instances of this EntityType, with 
the particular Thing as their superior (ie: having matching 

15 ThingID) . For each found instance, another sub-process is 

initiated, which comprises Steps 3 and 4. 

3. For each entity instance matching the Thing, the entity's 
particular data is retrieved. 

4. The new data is passed as arguments in a RegisterEntity ( ) 
20 call, to load the found entity into memory. Control then 

passes back to Step 2, to search for the next matching 
instance . 

5. Once each entity type has been fully searched, control passes 
back to Step 1. If all intermediate types are complete, it 

25 passes on to Step 6. 

Section II . 

6. With the intermediate types complete, the processing of 
Decisions is now initiated. A loop is initiated, wherein the 
Decisions table is searched for decisions subordinate to the 

30 required Thing (matching 'ThingID 1 ). For each matching 

decision, a sub-process is initiated, comprising steps 7, 8 
and 9. 

7. For a matching decision, the data is retrieved from the table. 

8. From the Decision's ProposalRef ID Property, and following a 
35 call to Item(), a pointer to the Decision's Superior Proposal 

is retrieved. 

9. Proposal: Math: AddDecision ( ) is executed, see below and 
Figure 5. 
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10. Once all decisions matching the Thing have been processed, the 
process is complete. 



Math: AddDecision 

5 This function is called in NewEntity and LoadHierarchy above, 

and is illustrated in Figure 5 of the drawings. 
Argument : None . 

1. A determination is made as to whether the decision source is 
subordinate. If it is, control passes to Step 2. If it is 

10 not, control passes to Step 3. 

2. The procedure sets Cube=Derived Cube. 

3. The procedure sets Cube=Normal Cube. 

4. Cube : ApplyDecision ( ) , see below and Figure 6. This determines 
the quality and type for the selected cube. 

15 5. A determination is made as to whether the Decision Source is 
Normal (see Steps 1 to 3) . If it is, control passes to Step 
6. If it is not, control passes to Step 7. 

6. Math: Add Decision to Hierarchically Superior Entity. 

7. A determination is made as to whether the Proposal has a 
20 Sibling Ref. If it does, control passes to Step 8. If it 

does not, control passes to Step 9. 

8. Math: Add Decision (Sibling) to Sibling Proposal. 

9. A determination is made as to whether the Proposal is derived 
from another Proposal. If it is, control passes to Step 10. 

25 If it is not, control passes to Step 11. 

10. Math: Add Decision (Derived) to DerivedFrom Proposal. 

11. Processing complete. 

Cube : ApplyDecision ( ) 

30 This is the facility to increment the Decision cube's data 

which is called in Math: AddDecision above, and is illustrated in 
Figure 6. 

Arguments: Decision parameters. Decision Quantity. 

1. This process needs to translate the decision parameters into a 
35 node location. It therefore iterates through each of the 

decision parameters. 

2. Selecting the Decision Dimension Key for each parameter in 
turn . 
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3. It translates the key into an index into that dimension of the 
cube. (See Decision Cube.) 

4 . The set of key indices thus obtained then form a vector into 
the cube, so selecting a particular node in the array. 

5. The node at this key is then incremented by the noted 
quantity . 

6. The derived fields in the decision schema are then 
recalculated. 

7. The process is then complete. 

Item() 

This function is called in RegisterEntity above, and is the 
facility to retrieve a pointer to a member entity, and is 
illustrated in Figure 7. 
Arguments: Entity Key 

1. From the Entity Key supplied, the collection of similar 
EntityTypes in memory is searched, to discover whether or not 
the Entity is already in memory. If it is, the process moves 
to Step 4, and returns a pointer to the entity. 

2. If the entity is not in memory, the process calls the Item() 
function with the Entity's ThingID to get a pointer to the 
superior Thing. 

3. Since a call to Item (ThingID) always loads the full hierarchy, 
subsequent new entities will also be directly loaded into 
memory. Step 3 is not a process, but simply acknowledges that 
Thing, and its full hierarchy, including the required Entity, 
will be in memory at this time. 

4. The collection of the EntityTypes will now be searched again, 
and the appropriate pointer returned to the calling function. 

5. The process is complete. 

Math : GetMathValue . 

This is illustrated in Figure 8 of the drawings. This 
function can be called by a Client system, in order to find out the 
current status of the computer system. 
Argument : None . 
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1. A determination is made as to whether the decision source is 
subordinate. If it is, control passes to Step 2. If it is 
not, control passes to Step 3. 

2. The procedure sets Cube=Derived Cube. 
5 3. The procedure sets Cube=Normal Cube. 

4. Cube: GetValue(), see below and Figure 9. The value is 
retrieved from the selected cube. 

5. Processing complete. 



10 Cube: GetValue() 

This is the facility to retrieve the Decision cube's data 
which is called in Math: GetMathValue , and is illustrated in Figure 
9. 

Arguments: Decision parameters. Decision Quantity. 
15 1. This process needs to translate the decision parameters into a 

node location. It therefore iterates through each of the 

decision parameters. 
2. Selecting the Decision Dimension Key for each parameter in 

turn. 

20 3. It translates the key into an index into that dimension of the 
cube. (See Decision Cube) 
4. CubeKey=Vector (DimensionKeys) . The set of key indices thus 
obtained then form a vector into the cube, so selecting a 
particular node in the array. 
25 5. The value of the node at this cube key is then retrieved. 
6. Processing complete. 

COMPUTER RESOURCES & SPECIFICATION 
While not restricted to these particular resources, the 
preferred embodiment of the system has been implemented on computer 
30 systems currently available. 

The prototype of the system was developed on a 133 MHZ Pentium 
Notebook PC with 32Mb RAM (random access memory) , and a 2Gb Hard 
Disk, running Microsoft Windows NT, with Microsoft Access as the 
Database, and with the software developed and prototyped both in 
35 Microsoft Visual Basic 5, and Microsoft Visual C++. 

The system was then ported to a Sun Microsystems UltraS, 
running Solaris 2.51, with a Sybase System 11 SQL Server database 
resource, and written in Unix/Ansi C++. 
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Thus, the key requirements of the system are readily met by 
the conjunction of a typical computer system, a typical software 
coding language, and a typical database resource. 



5 SOFTWARE DESIGN 

It is readily understood that software design and 
implementation must take into account the possibility of function 
calls failing for numerous causes. Since this is a fundamental 
requirement in software engineering, which must be managed in any 

10 commercial implementation, the needs and skills appropriate to 

support failure will therefore be familiar to any software engineer 
skilled in the art. As such, they do not feature as an aspect of 
the claims of the system, such routines and techniques for 
developing robust code have been considered immaterial to the 

15 explicit description of the particular embodiment of the system. 

SCOPE OF THE PREFERRED EMBODIMENT 
The preferred embodiment implements a fixed and limited 
hierarchy, of specified types yet which is of sufficient power to 
20 provide a modelling and management facility which will cope with 
typical transactions and negotiations encompassed in the world 
today . 

In combination with a facility to provide agents for execution 
of processes, it then encompasses a uniform and general transaction 

25 facility, suitable for example business, domestic, military and 

governmental use. 

To the extent that these agents may themselves be computer 
processes, then such an environment offers a computerised 
transaction facility. Where these agents do not need to refer to 

30 non-computer resources for their information to fulfil their 

transactions, then to that extent, the environment so described 
becomes an automated one. 



DATABASE 

35 For each entity type there is a corresponding database table. 

The table is given the name of the entity type. Thus, the existence 
of a 'Thing 1 entity leads to the existence of a 'Thing' table. 
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THING TABLE 

The Thing Table contains references to objects external to the 
system. Each new Thing record added to the table has a unique 
ThinglD. 

5 



Field Name 


Type 


Notes on Usage 


ThinglD 


Long 


Uniquely identifies 
a Thing 


ClientSystem 


String 


Identifies the 
Client System 


ClientSystemRef erence 


Long 


Identifies the external 
object in the Client System 


CI ient Re f Description 


String 


Optional - Description 
for client convenience 



ASSIGNMENT TABLE 

The Assignment Table contains references to processes to be 
10 applied to Thing entities. Each new Assignment record added to the 
table has a unique AssignmentID . 



Field Name 


Type 


Notes on Usage 


AssignmentID 


Long 


Uniquely identifies an 
Assignment 


ThingRef ID 


Long 


Thing this Assignment is 
for 


Instigator 


String 


Supplied by client to 
identify who created 
entity 


Insti gator Re f 


Long 


Supplied by client as 
external reference to 
Instigator 


PredecessorAssignmentRef ID 


Long 




Redirection 


String 


Precise nature of 
assignment 


Quantity 


Double 


How much of the 
redirection is requested 


The following fields can optionally be included: 


Deadline 


Date 


Date (including time) by 
which an assignment must 
be complete 


Pref erredByDate 


Date 


Date (including time) by 
which it would be 
preferred to have the 
assignment complete 
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TENDER TABLE 

The tender table contains the information which groups 
proposals. Each new Tender record added to the table has a unique 
TenderlD. 

5 



Field Name 


Type 


Notes on Usage 


TenderlD 


Long 


Uniquely identifies a Tender 


ThingRef ID 


Long 


Thing this Tender is for 


AssignmentRef ID 


Long 


The superior Assignment in the 
hierarchy 


Instigator 


String 


Supplied by client to identify 
who created entity 


InstigatorRef 


Long 


Supplied by client as external 
reference to Instigator 


Quantity 


Double 


How much this tender relates to 
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PROPOSAL TABLE 

The Proposal contains details of the negotiation with an agent 
to perform the process. Each new Proposal record added to the table 
has a unique ProposallD. 

5 



Field Name 


Type 


Notes on Usage 


ProposallD 


Long 


Uniquely identifies a 
Proposal 


ThingRef ID 


Long 


Thing this Proposal is for 


AssignmentRef ID 


Long 


The superior Assignment in 
the hierarchy 


TenderRef ID 


Long 


The superior Tender in the 
hierarchy 


Instigator 


String 


Supplied by client to 
identify who created entity 


Inst i gat or Re f 


Long 


Supplied by client as 
external reference to 
Instigator 


Sups riorProposalRs f I D 


Long 




SiblingProposalRef ID 


Long 




Upline 


String 


Who has an interest in the 
process being performed 


Downline 


String 


Who will perform the 
process - - 


GoingUp 


Boolean 


Who initiated the proposal 


BidWanted 


Boolean 


Does acceptance grant right 
to act 


Action 


String 


The action in regard to 
performing the process 


ConsiderQuant ity 


Double 


How much of the action is 
proposed 


The following fields can optionally be included: 


ReplyRequiredByDate 


Date 


Date by which the right to 
make a decision 
(particularly 
accept/decline) expires 


CompletionRequiredByDate 


Date 


Date by which the accepted 
quantity must be complete 



DECISION TABLE 



Field Name 


Type 


Notes on Usage 


DecisionID 


Long 


Uniquely identifies a Decision 


ProposalRef ID 


Long 


Uniquely identifies a Proposal 


Instigator 


String 


Supplied by client to identify 
who created entity 


InstigatorRef 


Long 


Supplied by client as external 
reference to Instigator 


ConsiderQuant it 

y 


Double 
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Double 


A response, Amount declined from 
proposal 


AcceptQuantity 


Double 


A response, Amount accepted from 
proposal 


ForwardQuantity 


Double 


A response, Amount forwarded 
from proposal 



INSTIGATOR AND INSTIGATOR REFERENCE 

At the creation of an entity record, the client system can 
5 provide two references. One is the instigator of the entity 

creation, and the other is a meaningful reference to the instigator. 

These fields are available for each entity type, however, they 
are of particular significance to the creation of Thing entities. 

10 
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DECISION SCHEMA 

The preferred embodiment implements a three-dimensional 
decision schema, with dimensions: 
Action, Authority and Resolution. 



10 



15 



20 



25 



30 



Direct fields : 

Direct fields represent the immediate description of the 
decision. The Index for each dimension in this embodiment is noted 
in brackets. 



Action : 

[0] Do: 

[1] NotDo: 

[2] Done: 

Resolution : 

[0] Consider: 

[1] Annul: 

[2] Decline: 
[3] Accept: 
[4] Forward: 



The potential exists that something be 
done . 

The potential no longer exists for something 
to be done . 

The claim is that something has in fact 
been done. 

It is being put to an agent to (action) 
something. 

The (action) is no longer available for 
consideration . 

The agent declines to pursue the action. 
The agent accepts to pursue the action. 
The agent accepts the responsibility for 
the action but will not perform the 
action . 



Authority : 

[0] FullAuthority : 

[1] BidWanted: 



Upon acceptance, the agent is free to 
pursue the action. 

There is no authority to pursue the 
action . 



Notes to clarify the above: 

Consider - the preferred embodiment embeds this in the proposal. It 
35 is necessary for the logical process that it be part of the 

decision schema, but it more naturally represents the 
opportunity or quantity to be decided upon. 
Annul - allows the modelling of the withdrawal of an offer, rather 
than the offer being declined by the invitee. 
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Forward - allows the modelling of the situation where a salesman 

accepts a client order, but will not be fulfilling it himself. 
It will be fulfilled, for example, by the factory floor. 

BidWanted - allows a tender for a contract to be modelled, or an 
5 offer of tickets, where the final allocation will be at the 

discretion of the offeror, not the bidder. 

In the following, these are written in the order: 

Resolution .Action .Authority . 

10 Derived Fields: 

Given the events (decisions) it is then appropriate to ask 
what the current situation is. The creation of derived fields 
therefore allows logical processing or mathematics to be done on the 
direct fields. The preferred embodiment implements the following 

15 derived fields. Calculations to generate the derived fields are 

noted beside the field description. The Identifiers are taken to 
indicate the values or quantities associated by those identifiers. 

For example: (Do - NotDo - Done = Open) should be read as: 
If quantity required as "Do" = 12, and quantity to "NotDo" = 5 and 

20 quantity claimed as "Done" = 3, then the quantity remaining "Open" 
is 12 - 5 - 3 = 4, ie 12 minus 5 minus 3. 
Dimension Indices are in brackets. 

Action 

25 [3] Open: (Do - NotDo - Done) Everything not cancelled or 

complete 

Resolution 

[5] Available: (Consider - Annul) Everything not withdrawn 

30 [6] Potential: (Available - Declined) Everything not declined 

[7] Pending: (Potential - Accept - Forward) 

Everything not decided 

Authority 
35 No derived fields 

Examples 
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Natural examples of decisions which may be expressed in this 
schema therefore are: 

Accept. Do Accept to do something. 
Decline. Do: Decline to do something. 

5 

Extending slightly: consider the following. 

Accept. NotDo Accept to NotDo something (eg: cancel an 

order) 

Decline .NotDo Declines to NotDo something (eg: too late to 
10 cancel . ) 



Consider further: 

Accept. Done: Accepts that something has been done. 

Decline . Done : Decline to recognise that something has been 

15 done. 



In the context of the system, a Do recognises the intent or 
potential to Do something, so that to Accept. Do for example sets up 
an expectation that whatever is being referred to will in due course 
20 be done . 

To recognise a Do is therefore to OPEN a potential. To CLOSE 
a potential, so that it can be dismissed from attention, one of two 
things must happen. Either it will in due course be Done or a 
subsequent agreement will be set up to NotDo that which is being 
25 referred to. 

The set [Do, NotDo, Done] therefore reflects a fundamental and 
natural set of potential intents, actions or claims. Given a 
potential that something can be done, so the process is initiated or 
OPENED as a Do; and it remains OPEN until either there is a matching 
30 NotDo, or it is Done. Whereupon it is in effect CLOSED and requires 
no further attention. 

In the example outline above the decision cube will have 
dimensions [4] [8] [2] and each element of the array will be 
initialised to zero. 

35 

Worked Example 

This will apply 2 decisions to a Cube. The first will reflect 
asking someone to consider doing 12 of something (buying 12 bottles 
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of water, for example) . The second will reflect the agreement of 
the individual to the proposal. The details of the nature of the 
transaction are not stored in nor relevant to either the cube or the 
system itself. Rather, only references to the existence of the 
5 transaction are stored. The system manages and captures the 

complexity of the negotiation, but leaves the description of the 
transaction to the client system. 



Decision 1: Asking someone to consider doing 12 of 

10 something. 

Decision Specification : Narrative /Intuitive description : 

Resolution: CONSIDER Please consider the following proposal 

Action: DO to do 

Quantity: 12 12 (of something) 

15 Authority: FULL with my permission to proceed, if you accept. 

Cube Vector: 

(Do = 0, Consider = 0, Authority = 0): Vector = (0,0,0) 

20 Cube Node: 

The active node is therefore Cube[0] [0] [0] . 



Incrementing the value: the node's value is increased by the 
decision quantity . 
25 Cube [0] [0] [0] = Cube [ 0 ] [ 0] [ 0 ] + 12; 



The node Consider . Do . Full is now 12. 



Recalculation of the derived fields 
30 Only a typical case is shown here, for illustration. 

Available . Do. Full = Consider . Do . Full - Annul . Do . Full = 12 - 0 = 12 



The invitee accepts 8 of the proposal 
Accept . Do . Full 
8 

[Do= 0] [Accept = 3] [ FullAuthority = 0] 
Implementation : 



Decision 2: 
Decision Type: 
35 Decision Quantity: 

Decision Vector: 
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Cube[0] [3] [0] = Cube[0] [3] [0] + 8; 



Restricting to the Do. Full indices, the Resolution dimension 
therefore now looks as follows: 

5 



Resolution 


Quantity 


Consider 


12 


Annul 


0 


Available 


12 


Declined 


0 


Potential 


12 


Accept 


8 


Forward 


0 


Pending 


4 



For a given Action therefore, 2 key foci exist: 
10 How much has been Accepted; and how much is still Pending. 

The first acknowledges a commitment to something, allowing planning. 
The second, unresolved but potential commitments, require follow-up. 

FURTHER EMBODIMENT 
15 The system itself is not limited to or by the preferred 

embodiment. A more sophisticated embodiment may be implemented 
without impinging upon or materially reshaping the fundamentals of 
the system herein described. Some of the additions to the preferred 
embodiment are now outlined. 

20 

ENTITY PROPERTIES 
The system may include the entity property EntityCreatedAT to 
store its TIME of creation. 

The system may include the entity property EntityVoid to 
25 support a facility to remove an Entity from consideration, in effect 

deleting it without actually removing it from the database. 

The system may include the entity property EntityClosed to 
enable a client to decide not to post any further transactions to 
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that entity. Note that this restriction would not be controlled by 
the system but by the client system, otherwise it violates the 
'Reflect don't Control' principle of the system. Additional 
properties which suggest internal control should be avoided or 
5 renamed. 

An Assignment entity may include further information above and 
beyond the simple identification of the transformation. For 
example, if a further embodiment of the system were to support 
deadline modelling, a deadline for the Assignment might be further 
10 included as a field in the Assignment entity. 

AUDIT TRAIL 

The system may include an audit trail to record the details of 
all transactions passing through the system. 

15 

MATH IN MEMORY 

The system may include storing the complex calculations in 
memory to speed up the overall performance. 

20 ADDITION FUNCTIONS FOR CLIENT SYSTEMS 

The system may include further facilities to enrich the range 
of the functionality available to the client system. An example is 
a query facility, taking advantage of the fact that the storage of 
..the embodiment is a database, so that client applications may 
25 implement queries such as: 

Assignments outstanding: Assignments not Closed, Pending 

non-zero 

Assignments overdue: Assignments not Closed, Created 

before X Date 

30 Agreements in place: Proposals with Downline=Y 



DELETING ENTITIES 
The system may include a facility to delete entity data. In 
the preferred embodiment no such facility exists. It is a design 
35 principle that the system does not 'forget' or 'lose* information. 
The preferred embodiment regards data deletion, therefore, as an 
internal housekeeping function for the user. 



30 



Clearly, on limited capacity machines, an unconstrained policy 
of adding data without any facility for deletion will overwhelm the 
resources at some point. Therefore, a policy on deletion of data 
would be prudent. This will typically depend on the rate of 
5 accretion of new data, the importance of the data, the resources 

available, and policy on data storage, archiving etc. 
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